home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Gold Collection
/
Software Vault - The Gold Collection (American Databankers) (1993).ISO
/
cdr12
/
dkit0593.zip
/
DNEKOPOL.002
< prev
next >
Wrap
Text File
|
1993-03-11
|
22KB
|
519 lines
DoorNet Backbone Operating Procedures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"This document adopted this 10th day of March 1993."
Table of Contents
~~~~~~~~~~~~~~~~~~~
Purpose of this Document
Brief Description
Zone Echomail Coordinator
Zone Hubs
Eroster/DnetStat.mdd
Region Echomail Coordinators
Region Hubs
Backbone Conference Moderators
Duties of Moderators
Recognition of Moderators
Operating Procedures
Echomail Message Standards
Adding Conferences to the Backbone
Removing Conferences from the Backbone
Routed Netmail
Gating Backbone Mail
Encryption
Echo Conference Criterion
General Conferences
Restricted Conferences
Specific Support Conferences
Changes to this Document
Purpose of this Document
~~~~~~~~~~~~~~~~~~~~~~~~
This document sets forth the operating procedures used by the DoorNet
Backbone Echomail System at the International level. It describes how
the Zone Hubs (Stars), International and Zone Echo Coordinators and
Regional Echo Coordinators make up the "Backbone" system for echomail
distribution.
Any part of this policy which conflicts with Local, State or Inter-
national Laws shall be deemed obsolete. Changes necessary to overcome
any conflicts shall be amended immediately by the appropriate IZ/ZC/ZEC
until such a time they can be ratified into this document.
(The operation of the Backbone within a region or net is not covered by
this document.)
An echomail conference is a message base or forum, distributed under a
specified echomail conference name, dealing with a defined area of
interest. Echomail conferences are hereafter referred to simply as
conferences.
Echomail Hubs are nodes who distribute echomail. The Echomail Hubs
are hereafter referred to simply as Hubs. Zone Hubs distribute
echomail at the zone level. Region Hubs distribute echomail at the
region level. Net Hubs distribute echomail at the net level.
Zone Echomail Coordinator
~~~~~~~~~~~~~~~~~~~~~~~~~
The Zone Echomail Coordinator (ZEC) oversees the operation of the
Backbone at the zone level. The ZEC coordinates routing and schedules
to ensure reliable and efficient availability of Backbone echomail
while avoiding creation of duplicate messages. The current ZEC can be
identified from the "DOORNET_ZEC", or the 75/1 - 76/1 listing in the
Dnetlist.
Eroster/DnetStat.mdd
~~~~~~~~~~~~~~~~~~~~
The ZEC maintains a list of Backbone conferences in a text file called
DOORNET.NA, also distributed in archived format under EROSTER.mdd
This file must be reformatted to be used as a forward-list by programs
such as AreaFix. The ZEC also maintains a list of conferences seeking
to be added to the Backbone. This is a text file called DNETSTAT.mdd.
The ZEC distributes these files to the Zone Hubs on a bi-weekly basis.
DNETSTAT.mdd will include submissions received via netmail or posted
within the D_ECHOREQ conference "To:" either "Steve Lin" or "ZEC" using
an appropriate subject heading. DNETSTAT.mdd will contain submissions
for backbone status for no less than 90 days of inclusion. The following
format will be used: <if I was the ZEC I'd write a program for this ;)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Submission Date: Echo Tag:
Description :
Current Path : List of system aka's currently receiving conference
REC Votes : List of RECs currently supporting conference
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The following syntax: EROSTER.mdd, where the "m" is a hexadecimal specifier
from 1 to C that designates the month in which the Echo Roster has been
released, and the "dd" is a decimal specifier from 01 to 31 that designates
the day in which the Echo roster has been released. This method of naming
the Echo roster archive makes it very easy for a sysop to determine which
Echo roster is the most recent in a certain year. Note that there is a
rollover phenomenon at the beginning of each year. We recommend that older
Echo rosters be deleted in favor of new ones. DNETSTAT.mdd follows this
same order of specifiers.
Zone Hubs
~~~~~~~~~
The ZEC appoints Zone Hubs (Stars) to distribute Backbone echomail at
the zone level. The ZEC may also serve as a Zone Hub if s/he so
desires.
Each Zone Hub carries all of the Backbone conferences. Each also
distributes the EROSTER.mdd and DNETSTAT.mdd files, as received from the
ZEC, to the Region Hubs they connect with.
The ZEC and Zone Hubs maintain an emergency backup plan should one of
the Zone Hubs experience problems.
Region Echomail Coordinators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Region Echomail Coordinator (REC) oversees the operation of the
Backbone at the region level. The REC coordinates routing and
schedules to ensure reliable and efficient availability of Backbone
echomail while avoiding creation of duplicate messages. The current
RECs can be identified from the ,1,Regional_Echo_Co or the xxx/1 (where
"xxx" = the region number) listings in the Nodelist.
Region Hubs
~~~~~~~~~~~
The REC appoints Region Hubs to distribute Backbone echomail at the
region level. The REC may also serve as a Region Hub if [s]he so
desires.
The REC decides which Region Hub connects to each of the Zone Hubs.
Each REC and Regional Hub carries all of the Backbone conferences. Each
also distributes the EROSTER.mdd and DNETSTAT.mdd files, as received from
the ZEC/REC respectively, into the Region's networks they connect with.
The REC and Regional Hubs maintain an emergency backup plan should
one of the Zone Hubs, REC and/or Regional Hubs experience problems.
Region Hubs make available all of the Backbone conferences with
exceptions to be noted later about restricted echo access.
Nothing in this provision requires that a REC or Region Hub must
import any conference to the extent of adverse economic impact.
Backbone Conference Moderators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Backbone Conference Moderators (Moderators) preside over conferences.
The Backbone has no desire to interfere with the internal affairs of a
conference in so much as they do not disturb the operation of the
Backbone.
A Moderator need not be either a Sysop or a member of Doornet. If the
Moderator is not a member of Doornet, s/he must list an address in a
publicly available Dnetlist of any network, so that s/he can be
contacted if the need arises via netmail.
Duties of Moderators
~~~~~~~~~~~~~~~~~~~~
IZEC is moderator of D_Moderator Echo or may designate someone to that
position in his/her place.
IZC is moderator of D_SYSOP and D_COORD and may appoint
or designate others to assist if needed.
Moderators are responsible for:
1) Seeing that messages in their conference correspond to the
conference's theme.
2) Updating their conference listing with the ZEC via netmail
so the appropriate modifications can be noted in EROSTER.mdd
If a Moderator believes that a node is violating a conference rule,
s/he may authorize the feed to that node be severed. This
authorization is made in direct written form (netmail), to the Hub
feeding the offending node, with a copy to the offending node.
Recognition of Moderators
~~~~~~~~~~~~~~~~~~~~~~~~~
A Moderator is recognized as follows:
1) Upon formation of a conference, the person who forms the
conference is the Moderator.
2) Upon resignation or replacement of an existing Moderator, the
conference's rules define how the new Moderator is selected.
3) Should a conference which originates inside of DoorNet be
without a moderator for over 30 days, the ZEC may select
a new Moderator.
Moderators are encouraged to appoint Co-Moderators to assist them in
their duties and to stand in for them in their absence.
Operating Procedures
~~~~~~~~~~~~~~~~~~~~
Echomail Message Standards
~~~~~~~~~~~~~~~~~~~~~~~~~~
FTSC specifications FTS-0001 and FTS-0004 are followed. All Backbone
nodes use the pathline option to comply with network addressing.
Adding Conferences to the Backbone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ZEC will add conference(s) to the Backbone when the following
requirements are met:
1) The conference is listed in the published EROSTER.mdd
2) The moderator either sends a netmail request to the ZEC or
posts the request, addressed to "Backbone", in the
D_ECHOREQ conference.
3) Four (4) RECs request that the Backbone carry the conference to
their regions to the ZEC either via netmail or within the
D_ECHOREQ conference.
Removing Conferences from the Backbone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ZEC may drop a conference from the Backbone when any of these
situations occur:
1) The conference is not updated in the EROSTER.mdd at least
once every 6 months by the Moderator.
2) The moderator either sends a netmail request to the ZEC or
posts the request, addressed to "Backbone", in the D_ECHOREQ
conference.
3) There are no longer four (4) RECs requesting that the Backbone
carry the conference to their regions.
4) The Moderator fails to properly carry out his/her duties,
as described in "Duties of Moderators".
5) The conference is without a Moderator for over 30 days.
6) The traffic level in the conference falls below 5 messages
over a two month period.
If any of these conditions exist and noted by/to the ZEC, the ZEC will
either select/request volunteer(s) for a new Moderator (if condition #5
exists), or post a notification within the D_ECHOREQ conference
indicating that a particular conference will be removed in "30" number of
days unless conditions are changed to meet the above specifications.
Special Note: The above criterions for "Adding/Removing" Backbone
conference areas apply only to DoorNet(tm) areas.
Special considerations apply to the "Specific Support
Conference" areas as stated below under same.
Routed Netmail
~~~~~~~~~~~~~~
Backbone nodes accept routed netmail from any node who connects with
them for Backbone conferences. Any netmail message with a valid
Doornet destination, regardless of its origin, is accepted. Routed
netmail may be routed along echomail paths or to a ZC, RC, or NC who
has agreed to handle such mail.
Gating Backbone Mail
~~~~~~~~~~~~~~~~~~~~
Gating Doornet specific conferences is not allowed (e.g. D_xxxx). Any
product oriented conferences may be gated to/from Doornet at the
permission of the designated Moderator/Author.
Encryption
~~~~~~~~~~
The transportation of "encrypted" net/echomail via the Doornet Backbone
in the United States, using the software named "Pretty Good Privacy"
(currently version 2.1 released as PGP21.*) is not allowed. Due to
legal ramifications with licensing limitations of the PGP software or
"Pretty Good Privacy" in the United States, as stated in the file
named "PGPDOC2.*" under "Legal Issues". At such a time when the
licensing of "Pretty Good Privacy" software is either entered into the
Public Domain or readily available on an International level this network
will make provisions by vote for future allowance.
Echo Conference Criterion
~~~~~~~~~~~~~~~~~~~~~~~~~
This section reflects the operating guidelines for each member of DoorNet
in respect to the echomail conferences available via the "Backbone". It
will include operating aspects of "required", "general" and "restricted"
echo conferences. The individual conference name will be described in
detail via the EROSTER.mdd file distributed via DOORDIST the DFN filebone
area. This document will not use the echo tag names used for distribution
with the exception of the "required" and "restricted" conference(s).
Echo conference tag names used will be obtained from the current release
of EROSTER.mdd that can be file requested from any "Administration Node"
within Doornet. The status of conferences within the DNETSTAT.mdd file
will be made available upon achieving "Backbone" status.
General Conferences
~~~~~~~~~~~~~~~~~~~
The "General echo conferences" are public conference echo areas open to
all. The following conferences are required to be carried by all Doornet
members, and to be made available to the general public:
Echo tag Brief Description
~~~~~~~~ ~~~~~~~~~~~~~~~~~
D_ADVENTURE - Discussions about adventure, rpg, war door games... etc.
D_CHANCE - Discussions about door games of chance, chess, dice... etc.
D_DOORGAMES - General chit chat about any door game (Note naming - ok?)
D_ECHOREQ - Requests for new backbone, regional echos or removal of
D_FILES - Announcements of new releases of Doors and Door Utilities.
D_INTERBBS - Discussions about interbbs gaming, may be used to form games.
D_SPORTS - Discussions about sport related door games
D_TRIVIA - Discussions about trivia related door games
All other "general or public" conferences not listed here are listed as
such in the EROSTER.mdd. Please make all general "Backbone" areas
available to the general public.
Restricted Conferences
~~~~~~~~~~~~~~~~~~~~~~
The following conferences are considered restricted to certain group(s).
Some of which will be "required" conference areas and will be noted so.
Echo tag Brief Description
~~~~~~~~ ~~~~~~~~~~~~~~~~~
D_ADULT_DOORS- "Not Required" however this is a DoorNet specific echo.
Discussions of Doors that relate to mature (Adult) themes.
While profanity will not be tolerated, the sysop may consider
limiting the echo to users over 18 due to the nature of the
topics.
D_SYSOP - "Required" - for administration use and announcements.
Discussions pertaining to Doornet operations, changes and
policy amendments, ratifications, votes... etc.
D_DEVELOP - Door Author's support area, publicly released door or
door type utility a must for access. REC's must receive
netmail from the author requesting access to this
conference and from which node the author will access
said conference from.
D_MODERATOR - "Required" by Doornet Moderators and ZEC Only. Only
Moderators listed in the EROSTER.mdd can have access
to this area. (All RECs please note)
D_COORD - D_NC, D_EXEC, and D_RC will make up this area. We need
a conference to maintain a professional profile within
the network. If International, Zone or Regional contact
need to take place without the influx necessary from the
node level we can do it here and get fast results. All
*[E]C's should have access to this area.
All D_???????? conference areas are a "Trademark" of DoorNet(tm). Any
gating of DoorNet specific conference areas must be approved by IZC.
Specific Support Conferences
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The echomail distributed via means of Backbone routing specific to a
certain door or programming group will be supported by the Doornet
backbone with the appropriate requirements met. The criteria(s)
necessary for "Specific Support Conference(s)" to gain backbone status
are as follows:
a. The "Door or Group(s)" designated Author make a request
to the IZEC, ZEC and local REC to carry a new Product
Specific conference on the Backbone.
b. Request shall be made either via NetMail or within the
D_ECHOREQ conference area.
c. Door Author(s) shall commit time to promote and Moderate
requested conference area, or shall appoint a person
knowledgable of their product as Moderator/Liason
d. Door Author(s) will make attempts of recognition within
DoorNet generic conference areas to promote their product
and Special Support Conference area on a regular basis.
These mild guidelines are to promote the use of DoorNet(tm) by the
Door Authors. Backbone status of "Product Specific" conferences will
only guarantee said conference(s) will be available from the "Star"
systems. All *ECs will not be required to carry this class of
conference unless regional downlinks request it.
It will be left up to the Author or designated Moderator as to who can
access their conference, this of course maybe subject to ruling(s) of the
ZEC and associated council. Typically the designated Moderator will
either be one of, or the supporting Author(s) of said "DOOR" program(s).
Designation of access shall be listed in DOORNET.NA, meaning the
read/write access to the conference being:
General - Open to the public
Sysop - Sysop Only conference (R)
Beta - For noted Beta testers, Both Sysop and User (R)
whereas (R) is "Restricted". The following conference areas are currently
carried by the DoorNet(tm) backbone system. For a complete listing of
available areas, please see the latest EROSTER.mnn ...
Echo tag Brief Description
~~~~~~~~ ~~~~~~~~~~~~~~~~~
AOTD ----------------------------------------------------- AOTD Support
Restriction "None" Moderator: Steve Lin (75:75/1)
BOI -------------------------------------------- BBS Online Interface Support
Restriction "None" Moderator: Andrew Mead (75:7919/417)
DOORSOURCE ----------------------------------------------- DoorSource Support
Restriction "?" Moderator: Todd Miller (75:75/3)
DWARZNET ------------------------------------------------ Dragon Wars Support
Restriction "None" Moderator: Bruce Ruona (FN 1:2280/1)
IMPERIUM --------------------------------------------------- Imperium Support
Restriction "?" Moderator: Chris King (FN 1:103/315)
INTELECHARGE ---------------------------------------- Intelecharge Support
Restriction "?" Moderator: Pat Carter (75:7615/102)
INTELESYS ------------------------------------------- Intelesys Support
Restriction "?" Moderator: Pat Carter (75:7615/102)
MEP -----------------------------------------Minds Edge Productions Support
Restriction "None" Moderator: Dion Loy (75:8010/303)
MICRONET -------------------------------------------- Micronet Support
Restriction "?" Moderator: ???????
MELEE ----------------------------------------------- Banzai Software Support
Restriction "?" Moderator: Kevin Higgins (75:7719/1)
MCSOFT ------------------------------------------ Motor City Software Support
Restriction "?" Moderator: Peter Kling (75:7518/2)
MYCROFT -------------------------------------------- Mycroft Software Support
Restriction "?" Moderator: David Fife (75:100/1)
NUGI ---------------------------------------------- N.U.G.I. Software Support
Restriction "?" Moderator: Dave Wendling (75:7413/2)
PGWARE ------------------------------------------------------- PGWare Support
Restriction "?" Moderator: Scott Philips (75:75/3)
PONYWARE --------------------------------------------------- Ponyware Support
Restriction "?" Moderator: Craig Barnett (75:7602/2)
QENFORCE ---------------------------------------- QEnforce and QFront Support
Restriction "?" Moderator: Rob Kitteredge (??:???/???)
SUNRISE_DOORS ----------------------------------- Sunrise-80 Software Support
Restriction "?" Moderator: Al Lawrence (75:7404/2)
TDS_ECHO ---------------------------------------------- TDS File Network News
Restriction "?" Moderator: Adrian Ng (75:500/1)
TOPSOFT --------------------------------------------- TopSoft Product Support
Restriction "?" Moderator: John Richardson (75:7502/2)
WWCOMM ----------------------------------------- W & W Communications Support
Restriction "?" Moderator: Peter Woodmansee (75:7408/2),
Richard Wilkes (75:7408/2)
*Note: Make sure to see the latest EROSTER.* for an accurate listing
of available conferences that can be linked.
Changes to this Document
~~~~~~~~~~~~~~~~~~~~~~~~
"For voting purposes only the REC's of record may vote. An REC of Record
is the individual listed in the weekly nodelist immediately preceding the
vote. The ZEC only votes in the case of a tie to break the stalemate."
Appeals of ZEC rulings may only be made to the ZC who may rule on the
appeal, dismiss the appeal or refer it to the Executive committee for review.
Whatever the result of this action it is final. It is normally the policy of
the ZC to uphold decisions of the ZEC.
A change to this document may be proposed by any REC. If a second REC
concurs, the proposed change is voted on by all of the RECs. Notice
of such a vote is posted both in the D_SYSOP conference and EROSTER.mdd,
at least 30 days prior to the start of the voting period.
The RECs are expected to assess the opinions of the members within their
region, and to vote accordingly. The voting period is 14 days. More
than 50 percent of those voting must vote for a change for it to be
accepted. At least 50 percent of the RECs must vote before the amendment
can be ratified into this document.
=end=